Forum:Problems after replacing Firmware R1.8 with R1.98
Initially with a set top box connected via a composite lead, the TV via the HDMI port and an iomega WiFi dongle plugged into ScreenPlay Pro HD (SPPHD) USB port all running under R1.8: 1) Viewing and recording functions all operated correctly; 2) The remote control (RC) standby key put an innactive SPPHD into standby whatever was being displayed over the HDMI link. Pressing "standby" again brought the SPPHD back to life again with the same type of display e.g. "Menu screen" before and after or "Video IP" before and after. 3) After being put into standby from the RC the SPPHD made a scheduled recording and returned itself to "standby" mode afterwards; 4) When it was not on standby the SPPHD always appeared as a network item under Windows XP Home; 5) Files could be moved over the WiFi network between SPPHD and PC in both directions; 6) Names of files on the SPPHD could be edited from any WiFi linked PC. The firmware was upgraded from R1.8 to R1.98 with media files already on the SPPHD being retained. The two stage process went exactly as described on the PC and then on the TV screen. The WiFi dongle data and all deleted recording schedules were re-instated and the Spphd re-connected to the set top box and TV as before. The following performance changes were now noted: 1) When first switched on the all viewing and recording functions appeared to operate correctly; 2) The RC standby function was not available if the menu or any sub-menu was being displayed. Pressing the button then put the SPPHD into a "sulk". The orange led lit briefly but the blue light did not go out as with R1.8. In it's "sulk" state the TV set provides a "NO SYNC SIGNAL" message instead of an Spphd Menu screen and none of the RC buttons do anything! The only way to get the SPPHD out of it's sulk is to unplug the power lead at the back, plug it in again and press the RC "standby" key to get the "menu screen". 3)Standby only works after selecting Video Input on the menu. Pressing standby again turns the SPPHD back on and immediately displays the Video Input connection. All other RC keys now perform correctly. 4) The SPPHD only makes scheduled recordings if it is left on all the time with the blue light on. If a recording is scheduled and "standby" performed as shown in 3) above the recording takes place and the SPPHD goes into "Sulk" mode with the blue led on all the time. 5) When an instant recording is made (continuous/ 30 mins / 60 mins etc.) the SPPHD makes the recording and stays on afterwards (no sulk state found so far here). 6) After setting up network parameters the SPPHD was assigned a network address by a DHCP router almost immediately and this was shown on the SPPHD menu screen against WiFi connection; 7) After recovering from "sulk" conditions described above in 2)the WiFi is emasculated. The dongle's led does not light and the WiFi connection test fails. From this point WiFi can be restored by following item 3) above. 8) When the dongle is working properly the SPPHD can be mapped as a network drive by Windows XP Home. Given such a small and exclusive gateway to what is only a partial success via the "standby" key I am keener than ever in considering the re-installation of firmware R1.8. -- 15:26, March 12, 2010 (UTC) Spphd 18:56, March 7, 2010 (UTC) :Thanks for posting your experiences. I just recently upgraded to 1.98 myself but haven't tried extensive testing on it yet. --JCoug 04:40, March 8, 2010 (UTC) :Ok, update. I can't say that I am getting the same experiences. The DvdPlayer program on it does turn on the yellow light before passing control to the RootApp, which then turns it off. It does seem to take a little longer to shut off, but not much longer. So if the recording light is staying on, then it's crashing the in the RootApp. :I did have ONE time that the sulk state as you described it happened. I haven't had it happen since. I would suggest reflashing the firmware to see if maybe it will clear something that got messed up. There is a difference between standby with record schedule vs. standby without. Standby with record schedule actually goes into a low power standby and does NOT turn on the recording light while powering down. Standby without a recording schedule shuts off the power and does temporarily turn on the recording light. You also see the difference when you power back up. Turning it on from a low power standby does not display the Iomega Logo at the beginning, while turning it on from power off (either because you unplugged, or shut it off at the front panel, or just didn't have anything scheduled to record) does display the logo while it boots. :I have not experienced any network problems. But I have modified my player lately to do my own network recognition in the startup script, so that may have something to do with it. Wifi IP assignment is slow for me, as always. I'll test some of the other things you described another time. Daylight savings just kicked in and stole an hour of hacking/playing time away from me :( --JCoug 09:01, March 14, 2010 (UTC) :Update #2. Tested the recording / setting the recording / auto turn on and auto turn off. Everything appeared to be working just fine on mine. Wifi turned back on after booting with recording schedule set (I removed my individual hacks to confirm this). So again, I would recommend reinstalling the firmware to see if it takes care of your issue. --JCoug 06:49, March 15, 2010 (UTC)